Date: Tue, 9 Mar 93 04:30:07 PST From: Advanced Amateur Radio Networking Group Errors-To: TCP-Group-Errors@UCSD.Edu Reply-To: TCP-Group@UCSD.Edu Precedence: Bulk Subject: TCP-Group Digest V93 #65 To: tcp-group-digest TCP-Group Digest Tue, 9 Mar 93 Volume 93 : Issue 65 Today's Topics: ampraddr robot help (2 msgs) any lower version of nos (3 msgs) Baycom USCC card HELP: NOS/JNOS Shared Interrups. (2 msgs) HELP: NOS/JNOS Shared Interrupts hidden transmitter routing (2 msgs) TCP Window (2 msgs) Send Replies or notes for publication to: . Subscription requests to . Problems you can't solve otherwise to brian@ucsd.edu. Archives of past issues of the TCP-Group Digest are available (by FTP only) from UCSD.Edu in directory "mailarchives". We trust that readers are intelligent enough to realize that all text herein consists of personal comments and does not represent the official policies or positions of any party. Your mileage may vary. So there. ---------------------------------------------------------------------- Date: Mon, 8 Mar 93 14:23:34 EST From: John Ackermann AG9V Subject: ampraddr robot help To: tcp mailing list How do I tell the ampraddr robot how to delete an mx record? I have two old entries stuck in the database as follows: ag9v IN MX 10 schizo.samsung.com. ag9v IN MX 20 schizo.samsung.com. I've tried a couple of times to post a partial mx record, missing either the exchanger or the preference, but the robot bombs with an error. Is there any way to delete these guys via the robot? Thanks... John ------------------------------ Date: Mon, 08 Mar 93 22:49:56 MST From: Lyndon Nerenberg Subject: ampraddr robot help To: "John R. Ackermann" John Ackermann AG9V Try this ... ag9v in mx 10 delete ------------------------------ Date: Mon, 8 Mar 93 9:39:21 MST From: jsteinhu@nyx.cs.du.edu (Josh Steinhurst) Subject: any lower version of nos To: tcp-group@ucsd.edu I am sorry if this is the wrong place for this message, but it seems the closest. My question is, is thier any version of tcp/ip(for radio) that works at a lower level then nos. This would allow you to use normal individual tcp/ip programs (Such as nntp, and other things) over a radio link, that nos doesn't emulate. Once again I am sorry if this is dumb question (I don't yet have any packet setup, but am thinking of seting up packet for tcp/ip as I find normal AX.25 and TheNet rather boring.) However I do have a bit of Internet know-how... -- ------------------------------ Date: Mon, 8 Mar 93 13:56:29 MST From: "Marvin Match" Subject: any lower version of nos To: jsteinhu@nyx.cs.du.edu, tcp-group@ucsd.edu On Mon, 8 Mar 93 9:39:21 MST, Josh Steinhurst wrote: >I am sorry if this is the wrong place for this message, but it seems the >closest. My question is, is thier any version of tcp/ip(for radio) that >works at a lower level then nos. This would allow you to use normal >individual tcp/ip programs (Such as nntp, and other things) over a radio >link, that nos doesn't emulate. > >Once again I am sorry if this is dumb question (I don't yet have any >packet setup, but am thinking of seting up packet for tcp/ip as I find >normal AX.25 and TheNet rather boring.) However I do have a bit of >Internet know-how... >-- John, Stop appologizing! I've thought the same things. While I can't give you a good answer, you might want to look at the TCP-IP code available from Watterloo University in Canada. Remember that radio has it's own unique problems, and TCP-IP for a wire doesn't address them. Follow the discussions on tcp-group@ucsd for awhile and you'll start to understand what some of them are. A new discussion group is forming on a list-server at Pixar to discuss the various protocols as they apply (or don't apply) to amateur radio that you might be interested in. To subscribe send e-mail to: list-serv@pixar.com with a blank subject line and the body of the message being: subscribe advanced-packet Hope this helps, and I'd be interested in hearing your comments. Marvin Match ------------------------------ Date: Tue, 9 Mar 93 09:22:50 PST From: "Jerzy Tarasiuk" Subject: any lower version of nos To: "Marvin Match" > From: jsteinhu@nyx.cs.du.edu (Josh Steinhurst) > Message-Id: <9303081639.AA07749@nyx.cs.du.edu> > Date: Mon, 8 Mar 93 9:39:21 MST > From: "Marvin Match" > Date: Mon, 8 Mar 93 13:56:29 MST > Message-Id: <50190.match@[128.110.44.31]> I've though similar things, too - the modular NOS requested by Russ (6 Jul 92, 2a586eb5.crynwr, Subject: A simple, stable, nos, please!). But my problem is I don't seem wise enough to decide what should be modules specifications. And even memory model seems to be a problem: Russ suggested HUGE, this causes very little work to be needed to make it all working and very little advantages from the modularity. Someone suggested SMALL: its great advantage is ability to move module in memory or even swap it to disk (module has no reason to have any segment address in it), but it causes serious problems with memory allocation - there is no small-model heap for multitasking or memory allocation must move about hundred kilobytes, since any memory getten from malloc() is FAR (and note for easy relocation must not store its segment address anywhere in module, must store its HANDLE; and must not access it directly - must use kernel functions instead). Has anyone any thoughts/ideas/...etc. on this subject ? Where can get the TCP-IP code from Watterloo University ? 73's, JT ------------------------------ Date: Mon, 8 Mar 93 16:19:10 GMT From: A.D.S.Benham@bnr.co.uk Subject: Baycom USCC card To: dvalar@leon.nrcps.ariadne-t.gr, TCP-Group@UCSD.Edu >Has anybody ever used a USCC Baycom 4 port card with NOS??? >I cannot make it work. PLEASE HELP !!!!!!!! I am desperate. >73 Demetre SV1UY >E-mail dvalar@leon.nrcps.ariadne-t.gr Yes, one of the hub stations in Hertfordshire (north of London) is using one successfully with JNOS 108. It does need modifications to SCC.C (and a minor modification to SCC.H) in order to work. I've put the modifications into the code in such a way that the driver will still work with all the other SCC cards. Is there general interest in this code (the number of Baycom USCC 4-port cards around (at least in the UK) can be counted on the fingers of one foot) ? Andrew Benham -------------------------------------------------------------------- adsb@bnr.co.uk BNR Europe Ltd, London Road, Harlow, Essex CM17 9NA +44 279 402372 Fax: +44 279 402100 Home: g8fsl@g8fsl.ampr.org [44.131.19.195] G8FSL@GB3XP -------------------------------------------------------------------- ------------------------------ Date: Mon, 8 Mar 93 14:45:16 GMT From: Alan Cox Subject: HELP: NOS/JNOS Shared Interrups. To: aa6ed <@UCSD.EDU:aa6ed@algedi>, tcp-group@ucsd.edu Welcome to the wacky world of PC hardware The PC bus doesn't support multiple cards on a single interrupt properly. Multiple ports on a single card require some extra board logic, and normally extra software knowledge. The cl;aclassic example of this is the AST 4 port clones. If your card is really really smart just looping through all the ports that match the interrupt in the asyint() handler will do the trick. For most cards it will work for a bit and then a port will jam when the timing is just wrong. You _can_ drive multiple ports on an interrupt without any fancy hardware support but its very very hard and unpleasant and I know no version of NOS supporting that or even the AST 4 port additions. Alan ------------------------------ Date: Mon, 8 Mar 93 13:21:04 PST From: enge@almaden.ibm.com Subject: HELP: NOS/JNOS Shared Interrups. To: TCP-GROUP@UCSD.EDU In <5762.9303081445@pyr.swan.ac.uk> Alan Cox writes: >Welcome to the wacky world of PC hardware > >The PC bus doesn't support multiple cards on a single interrupt properly. >Multiple ports on a single card require some extra board logic, and normally extra >software knowledge. The cl;aclassic example of this is the AST 4 port clones. >If your card is really really smart just looping through all the ports that >match the interrupt in the asyint() handler will do the trick. For most >cards it will work for a bit and then a port will jam when the timing is just >wrong. You _can_ drive multiple ports on an interrupt without any fancy >hardware support but its very very hard and unpleasant and I know no version >of NOS supporting that or even the AST 4 port additions. > >Alan > MBBIOS should operate properly with various shared interrupt schemes if you can use that from NOS. Roy, AA4RE ------------------------------ Date: Mon, 8 Mar 93 16:04:28 PST From: Bill Healy Subject: HELP: NOS/JNOS Shared Interrupts To: tcp-group@ucsd.edu (tcp-group) > Welcome to the wacky world of PC hardware > > The PC bus doesn't support multiple cards on a single interrupt properly. > Multiple ports on a single card require some extra board logic, and normally extra > software knowledge. The cl;aclassic example of this is the AST 4 port clones. > If your card is really really smart just looping through all the ports that > match the interrupt in the asyint() handler will do the trick. For most > cards it will work for a bit and then a port will jam when the timing is just > wrong. You _can_ drive multiple ports on an interrupt without any fancy > hardware support but its very very hard and unpleasant and I know no version > of NOS supporting that or even the AST 4 port additions. > > Alan Look a little harder if you think no version of NOS supports shared interrupts. Here's part of a message from Phil from April of last year, I think the code has since been included in JNOS as well. Bill N8KHN > Date: Sat, 11 Apr 92 16:07:06 -0700 > From: karn@chicago.Qualcomm.COM (Phil Karn) > To: tcp-group@UCSD.EDU > Subject: src0411.zip now on ucsd.edu > > Hi! > > Believe it or not, I have been busy recently on the base version of > NOS. I've just uploaded src0411.zip and net.exe to ucsd.edu, directory > /hamradio/packet/tcpip/ka9q. There are a LOT of changes in this code, > mostly below the surface. I'm not able to test everything to make sure > it all still works, so I would really appreciate it if people could do > that for me and let me know. In particular, I have not tested the > netrom, scc, drsi, hs, and arcnet network modules, and they may or may > not work. > > Here are the changes, in no particular order: > > 1. Optional IRQ chaining is now supported. If you suffix "C" to the IRQ > number in an attach command, e.g., > > attach asy 0x1a8 4c slip com2 1024 1500 19200 > > the com2 driver's interrupt handler will call whatever vector was > previously installed for IRQ 4 whenever it has finished servicing an > interrupt. So you can now attach all four ports of an AST 4-port serial > card in enhanced mode with the following commands: > > attach asy 0x1a0 4 slip com1 1024 1500 19200 > attach asy 0x1a8 4c slip com2 1024 1500 19200 > attach asy 0x1b0 4c slip com3 1024 1500 19200 > attach asy 0x1b8 4c slip com4 1024 1500 19200 > > Note that the first attach command didn't specify the 'c' flag, because > the pre-existing vector for IRQ4 at that point is the "dummy" IRQ > handler in the bios, and there's no need to call it. Things will still > work if the 'c' flag were specified here, but interrupt servicing would > take a little longer than necessary to call the do-nothing dummy vector > in the BIOS. > > You should also attach your fastest device last, since that will place > it first on the chain of interrupt handlers to be called. > > Note that the IRQ number is now expected to be in DECIMAL, not hex. Not > that it made much difference, of course, since most IRQ numbers that > people use are below 10. (This change was necessary, of course, to > prevent the 'c' flag from confusing the number-conversion routine). > > Those writing device drivers should note that this feature required > changes to the conventions used for interrupt handlers in NOS. In > particular, each interrupt handler (called from the assembler vector > hook) is expected to return the previous interrupt vector found at the > device's vector at attach time, or NULL if one didn't exist or was > invalid. The interrupt return assembler code (common to all interrupt > handlers) uses this return value to jump to the next interrupt handler > on the chain. > [stuff deleted] ------------------------------ Date: Mon, 8 Mar 93 10:08:34 PST From: jackb@mdd.comm.mot.com (Jack Brindle) Subject: hidden transmitter routing To: tony@mpg.phys.hawaii.edu >This discussion has got me wondering how to best handle full-duplex >operation over a path that has a long inherent time-delay relative to >the typical packet size. Specifically, suppose we had a high-orbit >satellite or (I wish) a geostationary satellite with a portion of it's >up and downlink spectrum dedicated for packet use in full-duplex >mode. This would be an ideal repeater at say 1200 BAUD rates. But when >you start looking at the quarter second delay between when a ground station >transmits and when its signal is detectable by other ground stations, it >seems to me that this inherent delay can cause some serious problems >at the higher BAUD rates. This is one situation that doesn't seem to >get that much better by virtue of having a full-duplex repeater >available. Wouldn't this require a fix of a different nature? >Perhaps some form of token bus? Actually the VSAT guys already seem to have this one figured out pretty well. They run transponders with multiple "low-rate" up channels, and a single high-rate down channel. The up channels typically run about 32kb to 56kb, while the down channel is around 512kb. The receive side of the satellite is around a meg or two wide, and can handle many simultaneous uplinks. They actually do place multiple stations on the same uplink frequency, accepting the possibility of collisions and handling this with the transport layer. I don't know if they use any collision avoidance system; maybe someone from Tridom or one of the other VSAT vendors could comment... I could see a ham satellite with a similar system, say a dozen or so 1200 baud up channels and a single 56k down channel. The math types would tell us that the probability of hitting full capacity on the up channels (to completely fill the down channel) is relatively low, so we could even design the up channels for higher capacity than the down channel. Buffering in the satellite would handle the short-lived peak times when the downlink couldn't keep up. Interesting... Jack Brindle ------------------------------------------------------------------------------ ham radio: wa4fib internet: jackb@mdd.comm.mot.com ------------------------------ Date: Tue, 9 Mar 93 0:08:49 HST From: Antonio Querubin Subject: hidden transmitter routing To: jackb@mdd.comm.mot.com (Jack Brindle) > >This discussion has got me wondering how to best handle full-duplex > >operation over a path that has a long inherent time-delay relative to > >the typical packet size. Specifically, suppose we had a high-orbit > >satellite or (I wish) a geostationary satellite with a portion of it's > >up and downlink spectrum dedicated for packet use in full-duplex > >mode. This would be an ideal repeater at say 1200 BAUD rates. But when > >you start looking at the quarter second delay between when a ground station > >transmits and when its signal is detectable by other ground stations, it > >seems to me that this inherent delay can cause some serious problems > >at the higher BAUD rates. This is one situation that doesn't seem to > >get that much better by virtue of having a full-duplex repeater > >available. Wouldn't this require a fix of a different nature? > >Perhaps some form of token bus? > > Actually the VSAT guys already seem to have this one figured out pretty well. > They run transponders with multiple "low-rate" up channels, and a single > high-rate down channel. The up channels typically run about 32kb to 56kb, > while the down channel is around 512kb. The receive side of the satellite > is around a meg or two wide, and can handle many simultaneous uplinks. They > actually do place multiple stations on the same uplink frequency, accepting > the possibility of collisions and handling this with the transport layer. I > don't know if they use any collision avoidance system; maybe someone from > Tridom or one of the other VSAT vendors could comment... > > I could see a ham satellite with a similar system, say a dozen or so 1200 > baud up channels and a single 56k down channel. The math types would tell > us that the probability of hitting full capacity on the up channels (to > completely fill the down channel) is relatively low, so we could even design > the up channels for higher capacity than the down channel. Buffering in the > satellite would handle the short-lived peak times when the downlink couldn't > keep up. The problem with this approach is that the maximum throughput any one station sees is limited to 1200 BAUD regardless of the channel usage. Yet we have satellites that can already do 9600 BAUD. We ought to be designing the next generation of packet satellites with the criteria that they run at LEAST as fast as 9600 BAUD and that the full bandwidth of the channel be available under the best of conditions. But suppose we don't have the best of conditions, ie. there are more than two stations are talking to each other on the same satellite channel. And suppose these stations are using the currently available technology (G3RUH or WA4DSY style modems). How does one go about picking the slot-time and p-persistence values to minimize collisions? Setting the slot-time to a quarter-second seems reasonable at 1200 BAUD, but seems less so at 9.6 or 56 kbps. Would using a slot-time equal to the maximum packet length be reasonable? In this case, I suppose we'd be accepting a greater chance for collisions in return for possibly higher throughput under low channel-usage conditions and the collisions handled by upper layer backoff algorithms. At 56 kbps, one could even think about doing collision detection between packet transmissions assuming the maximum packet size is chosen to never exceed a quarter-second transmission time. I can see a modified collision-detecting KISS that doesn't clear a packet from the transmit queue until it sees the packet echo from the satellite between transmissions. More exotic approaches might use some form of token-ring or time-multiplexing or a combination of the two. Not exactly sure how that would work though. Just thinking out loud folks. These problems have been bothering me for a while now and the current thread over reworking AX.25 caught my attention :-). Does anyone know of any papers that seriously analyse high-speed packet over high-orbit satellite links? Tony ------------------------------ Date: Mon, 8 Mar 93 13:43:30 GMT From: A.D.S.Benham@bnr.co.uk Subject: TCP Window To: TCP-Group@UCSD.Edu Apologies if this is old hat, but it's been causing confusion in South-East England for months. What was observed was that many stations were putting out TCP frames with the TCP window parameter = 2048. When asked to add a "tcp window 648" to their start-up file the reply was often "but I have that there already!". Anyway, at the weekend I was playing around with the possibility of different window lengths on different ports (so I can have a TCP window of 5000 or so on my shack Ethernet =without= this window also applying to the 2 metre radio port... I'd like to remain on friendly terms with the other users of the freq!). (Let's ignore whether this is good or bad practice.. it isn't the main point of this note). After a while I thought I'd achieved it (by adding a 'ifconfigure window' command - if set to 0 for a port, use the 'tcp window' setting). And sessions I created had the appropriate window size. =But= incoming sessions didn't, they always had the 'tcp window' setting as the window in the ACK SYN frame. After a bit of thought and reading the code, the tcp window for the ACK SYN frame must come from the server code and is presumably set when the 'start ' command is issued (although I must confess I couldn't find where the "rcv.wnd" gets set other than in the 'open_tcp' function in TCPUSER - in JNOS 108). So I played some more with the original code (i.e. without my window per port mod), with interesting findings- if the start-up file has: tcp window 648 start telnet start.... (rest of servers) tcp window 432 Then sessions initiated by me had a TCP window of 432, incoming sessions ACK SYN'd with a window of 648. I then played around with a local station who has the "window = 2048" problem outlined at the start. And, yes, sessions he initiated had the correct window, his replies to incoming sessions gave a window of 2048. A quick peep in his AUTOEXEC.NOS showed that he set 'tcp window' AFTER starting the servers. Having got him to set the tcp window =before= starting the servers it's all ok. Obviously it was picking up the DEF_WND value from TCP.H (2048) as the tcp window wasn't set. So, the moral is: set 'tcp window' before starting the servers. (I'm still uncertain as to whether this is a bug or a feature! I can't really say I'm totally happy that I've found where the "rcv.wnd" gets set for an incoming session request, but I presume it is in the open_tcp call when the server is started. In which case 'tcp window' is bound to give this slightly inconsistent behaviour. And for the time being, I've shelved my window per port idea!) Andrew Benham -------------------------------------------------------------------- adsb@bnr.co.uk BNR Europe Ltd, London Road, Harlow, Essex CM17 9NA +44 279 402372 Fax: +44 279 402100 Home: g8fsl@g8fsl.ampr.org [44.131.19.195] G8FSL@GB3XP -------------------------------------------------------------------- ------------------------------ Date: Mon, 8 Mar 93 15:21:26 GMT From: Alan Cox Subject: TCP Window To: A.D.S.Benham@bnr.co.uk, TCP-Group@UCSD.Edu What would be more useful is a 2K or so netrom tcp window and a smaller AX.25 window setting. I've sort of nailed it into the KA(Q net for unix I use Nail being the correct description - the tcp socket setup has a look at the routing and diddles the window setting. Alan ------------------------------ End of TCP-Group Digest V93 #65 ****************************** ******************************